---
title: Referência da Configuração
i18nReady: true
githubURL: https://github.com/withastro/astro/blob/main/packages/astro/src/%40types/astro.ts
---

import Since from '~/components/Since.astro';


A referência a seguir cobre todas as opções de configuração suportadas no Astro. Para aprender mais sobre como configurar o Astro, leia o nosso guia, [Configurando Astro](/pt-br/guides/configuring-astro/).

```js
// astro.config.mjs
import { defineConfig } from 'astro/config'

export default defineConfig({
  // suas opções de configuração aqui...
})
```
## Opções Top-Level


### root

<p>

**Tipo:** `string`<br />
**Interface de Linha de Comando:** `--root`<br />
**Padrão:** `"."` (diretório de trabalho atual)
</p>

Você deve apenas providenciar esta opção se você executar os comandos da interface de linha de comando `astro` em um diretório diferente do que o diretório raiz do projeto. Geralmente, esta opção é providenciada pela interface de linha de comando ao invés do [arquivo de configuração Astro](/pt-br/guides/configuring-astro/#tipos-de-arquivo-de-configuração-suportados), já que Astro precisa saber a raiz do seu projeto antes de poder localizar seu arquivo de configuração.

Se você providenciar um caminho relativo (ex: `--root: './meu-projeto'`) Astro irá resolvê-lo com base no seu diretório de trabalho atual.

#### Exemplos

```js
{
  root: './diretorio-do-meu-projeto'
}
```
```bash
$ astro build --root ./diretorio-do-meu-projeto
```

### srcDir

<p>

**Tipo:** `string`<br />
**Padrão:** `"./src"`
</p>

Define o diretório em que Astro irá ler o seu site.

O valor pode ser tanto um caminho absoluto do sistema ou um caminho relativo a raiz do projeto.

```js
{
  srcDir: './www'
}
```

### publicDir

<p>

**Tipo:** `string`<br />
**Padrão:** `"./public"`
</p>

Define o diretório de seus assets estáticos. Arquivos nesse diretório são servidos em `/` durante o desenvolvimento e são copiados para o diretório de saída durante o processo de build. Esses arquivos serão sempre servidos ou copiados da forma que são, sem transformações ou etapa de bundle.

O valor pode ser tanto um caminho absoluto do sistema ou um caminho relativo a raiz do projeto.

```js
{
  publicDir: './meu-diretorio-public-customizado'
}
```

### outDir

<p>

**Tipo:** `string`<br />
**Padrão:** `"./dist"`
</p>

Define o diretório em que `astro build` escreve a sua build final.

O valor pode ser tanto um caminho absoluto do sistema ou um caminho relativo a raiz do projeto.

```js
{
  outDir: './meu-diretorio-build-customizado'
}
```
**Veja Também:**
- build.server

### cacheDir

<p>

**Tipo:** `string`<br />
**Padrão:** `"./node_modules/.astro"`
</p>

Define a pasta para deixar em cache artefatos da build. Arquivos nessa pasta vão ser usados em subsequentes builds para acelerar o tempo de build.

O valor pode ser tanto um caminho absoluto no sistema de arquivos ou um caminho relativo a raiz do projeto.

```js
{
  cacheDir: './minha-pasta-de-cache-personalizada'
}
```

### redirects

<p>

**Tipo:** `Record.<string, RedirectConfig>`<br />
**Padrão:** `{}`<br />
<Since v="2.9.0" />
</p>

Especifica um mapeamento de redirecionamentos onde a chave é a rota a corresponder
e o valor é o caminho pra onde será redirecionado.

Você pode redirecionar tanto rotas estáticas como dinâmicas, mas somente o mesmo tipo de rota.
Por exemplo, você não pode ter um redirecionamento `'/artigo': '/blog/[...slug]'`.


```js
{
  redirects: {
    '/antigo': '/novo',
    '/blog/[...slug]': '/artigos/[...slug]',
  }
}
```


Para sites estaticamente gerados sem nenhum adaptador instalado, isso vai produzir um redirecionamento no cliente usando uma [tag `<meta http-equiv="refresh">`](https://developer.mozilla.org/pt-BR/docs/Web/HTML/Element/meta#http-equiv) e não suporta códigos de status.

Quando estiver usando SSR ou um adaptador estático no modo `output: static`,
códigos de status não são suportados.
O Astro irá servir requisições GET redirecionadas com um status de `301`
e usar um status de `308` para qualquer outro método de requisição.

Você pode customizar o [código de status de redirecionamento](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status#mensagens_de_redirecionamento) usando um objeto na configuração de redirecionamento:

```js
{
  redirects: {
    '/outro': {
      status: 302,
      destination: '/lugar',
    },
  }
}
```

### site

<p>

**Tipo:** `string`
</p>

Sua URL final no deploy. Astro utiliza esta URL completa para gerar seu sitemap e URLs canônicas na sua build final. É fortemente recomendado que você defina esta configuração para usufruir ao máximo o que o Astro pode oferecer.

```js
{
  site: 'https://www.meu-site.dev'
}
```

### compressHTML

<p>

**Tipo:** `boolean`<br />
**Padrão:** `true`
</p>

Esta é uma opção para minificar seu HTML final e reduzir o tamanho dos seus arquivos HTML. Por padrão, o Astro remove todos os espaços em branco do seu HTML, incluindo quebras de linha, de componentes `.astro`. Isso ocorre tanto em modo de desenvolvimento e na build final.
Para desabilitar a compressão de HTML, defina a flag `compressHTML` como `false`.

```js
{
  compressHTML: false
}
```

### base

<p>

**Tipo:** `string`
</p>

O caminho base no qual será feito o deploy. Astro irá utilizar esse caminho como a raiz para suas páginas e assets tanto em desenvolvimento quanto na build para produção.

No exemplo abaixo, `astro dev` irá iniciar seu servidor em `/docs`.

```js
{
  base: '/docs'
}
```

Au utilizar esta opção, todas as importações de assets e URLs devem adicionar a base como prefixo. Você pode acessar esse valor com `import.meta.env.BASE_URL`.

O valor de `import.meta.env.BASE_URL` respeita sua configuração de `trailingSlash` e irá incluir uma barra final se você explicitamente incluiu uma ou se `trailingSlash: "always"` foi definido. Se `trailingSlash: "never"` está definido, `BASE_URL` não irá incluir uma barra final, mesmo se `base` inclui uma.

Uma barra final sempre é incluída se `trailingSlash: "always"` estiver definido. Se `trailingSlash: "never"` estiver definido, `BASE_URL` não incluirá uma barra final, mesmo que `base` inclua uma.

Adicionalmente, Astro irá manipular internamente o valor configurado para `config.base` antes de torná-lo disponível para integrações. O valor de `config.base` lido por integrações também será determinado por sua configuração de `trailingSlash` da mesma forma.

No exemplo abaixo, os valores de `import.meta.env.BASE_URL` e `config.base` serão ambos `/docs` quando processados:
```js
{
  base: '/docs/',
  trailingSlash: "never"
}
```

No exemplo abaixo, os valores de `import.meta.env.BASE_URL` e `config.base` serão ambos `/docs/` quando processados:

```js
{
  base: '/docs',
  trailingSlash: "always"
}
```

### trailingSlash

<p>

**Tipo:** `'always' | 'never' | 'ignore'`<br />
**Padrão:** `'ignore'`
</p>

Define o comportamento de correspondência de rotas do servidor de desenvolvimento. Escolha entre as seguintes opções:
- `'always'` - Apenas corresponde URLs que incluem uma barra final (ex: "/foo/")
- `'never'` - Nunca corresponde URLs que incluem uma barra final (ex: "/foo")
- `'ignore'` - Corresponde URLs independente da presença de uma "/" final

Use esta opção de configuração se o seu host de produção lida de forma estrita em como barras finais funcionam ou não.

Você também pode definir isto se você preferir ser mais estrito consigo mesmo, para que então URLs com ou sem barras finais não funcionem durante o desenvolvimento.

```js
{
  // Exemplo: Requer uma barra final durante o desenvolvimento
  trailingSlash: 'always'
}
```
**Veja Também:**
- build.format

### scopedStyleStrategy

<p>

**Tipo:** `'where' | 'class'` | `'attribute'`<br />
**Padrão:** `'attribute'`<br />
<Since v="2.4" />
</p>

Especifica a estratégia usada para definir o escopo de estilos dentro de componentes do Astro. Escolha entre:
  - `'where'`     - Usa seletores `:where`, não causando aumento de especificidade.
  - `'class'`     - Usa seletores baseados em classe, causando um aumento de +1 de especificidade.
  - `'attribute'` - Usa atributos `data-`, causando um aumento de +1 de especificidade.

Usar `'class'` é útil quando você quer garantir que os seletores de elementos em componentes Astro sobrescrevam os padrões de estilo globais (e.x. de uma folha de estilo global).
Usar `'where'` dá a você mais controle sobre a especificidade, mas requer que você use seletores de especificidade mais alta, camadas e outras ferramentas para controlar quais seletores são aplicados.
Usar `'attribute'` é útil quando você está manipulando o atributo `class` de elementos e precisa evitar conflitos entre sua própria lógica de estilização e a aplicação de estilos do Astro.

### adapter

<p>

**Tipo:** `AstroIntegration`
</p>

Faça deploy para seu servidor de hospedagem, serverless ou edge favorito com adaptadores de build. Importe um dos nossos adaptadores oficiais para [Netlify](/pt-br/guides/deploy/netlify/#adaptador-para-ssr), [Vercel](/pt-br/guides/deploy/vercel/#adaptador-para-ssr) e mais para começar a usar SSR no Astro.

[Veja nosso guia sobre Renderização no lado do Servidor](/pt-br/guides/server-side-rendering/) para mais sobre SSR e [nossos guias de deploy](/pt-br/guides/deploy/) para uma lista completa de hospedagem.

```js
import netlify from '@astrojs/netlify';
{
  // Exemplo: Faça build para o serverless da Netlify
  adapter: netlify(),
}
```
**Veja Também:**
- output

### output

<p>

**Tipo:** `'static' | 'server' | 'hybrid`<br />
**Padrão:** `'static'`
</p>

Especifica o alvo de saída para builds.

- 'static' - Fazendo build de um site estático para fazer deploy em qualquer hospedagem estática.
- 'server' - Fazendo build de um app para fazer deploy em uma hospedagem que suporta SSR (renderização no lado do servidor).
- 'hybrid' - Fazendo build de um site estático com algumas páginas renderizadas no lado do servidor.

```js
import { defineConfig } from 'astro/config';

export default defineConfig({
  output: 'static'
})
```
**Veja Também:**
- adapter

## Opções da Build


### build.format

<p>

**Tipo:** `('file' | 'directory')`<br />
**Padrão:** `'directory'`
</p>

Controla o formato final do arquivo de cada página. Esse valor pode ser configurado por um adaptador para você.
  - Se for 'file', Astro irá gerar um arquivo HTML (ex: "/foo.html") para cada página.
  - Se for 'directory', Astro irá gerar um diretório com um arquivo `index.html` aninhado (ex: "/foo/index.html") para cada página.

```js
{
  build: {
    // Exemplo: Gera `pagina.html` ao invés de `pagina/index.html` durante a build.
    format: 'file'
  }
}
```



#### Efeito no Astro.url
Definir `build.format` controla o que `Astro.url` é durante a build. Quando ele for:
- `directory` - O `Astro.url.pathname` irá incluir uma barra final para imitar o comportamento da pasta; ou seja, `/foo/`.
- `file` - O `Astro.url.pathname` irá incluir `.html`; ou seja, `/foo.html`.

Isso significa que quando você criar URLs relativas usando `new URL('./relativo', Astro.url)`, você terá um comportamento consistente entre dev e build.

Para evitar inconsistências com o comportamento da barra final durante desenvolvimento, você pode restringir a [opção `trailingSlash`](#trailingslash) para `'always'` ou `'never'` dependendo do seu formato de build:
- `directory` - Defina `trailingSlash: 'always'`
- `file` - Defina `trailingSlash: 'never'`

### build.client

<p>

**Tipo:** `string`<br />
**Padrão:** `'./dist/client'`
</p>

Controla o diretório de saída do seu CSS e JavaScript do lado do cliente apenas quando `output: 'server'` ou `output: 'hybrid'`.
`outDir` controla onde o código é construído.

Esse valor é relativo ao `outDir`.

```js
{
  output: 'server', // ou 'hybrid'
  build: {
    client: './client'
  }
}
```

### build.server

<p>

**Tipo:** `string`<br />
**Padrão:** `'./dist/server'`
</p>

Controla o diretório de saída de JavaScript do servidor ao fazer build para SSR.

Esse valor é relativo ao `outDir`.

```js
{
  build: {
    server: './server'
  }
}
```

### build.assets

<p>

**Tipo:** `string`<br />
**Padrão:** `'_astro'`<br />
<Since v="2.0.0" />
</p>

Especifica o diretório na saída da build onde assets gerados pelo Astro (JS e CSS pós-bundle por exemplo) deve ficar.

```js
{
  build: {
    assets: '_customizado'
  }
}
```
**Veja Também:**
- outDir

### build.assetsPrefix

<p>

**Tipo:** `string`<br />
**Padrão:** `undefined`<br />
<Since v="2.2.0" />
</p>

Especifica o prefixo para links de assets gerados pelo Astro. Isto pode ser utilizado se assets são servidos de um domínio diferente do site atual.

Por exemplo, se ele é definido como `https://cdn.exemplo.com`, assets serão buscados de `https://cdn.exemplo.com/_astro/...` (independente da opção `base`).
Você precisaria fazer upload desses arquivos em `./dist/_astro/` para `https://cdn.exemplo.com/_astro/` para providenciar os assets.
O processo varia dependendo em como o domínio de terceiros é hospedado.
Para renomear o caminho `_astro`, especifique um novo diretório em `build.assets`.

```js
{
  build: {
    assetsPrefix: 'https://cdn.exemplo.com'
  }
}
```

### build.serverEntry

<p>

**Tipo:** `string`<br />
**Padrão:** `'entry.mjs'`
</p>

Especifica o nome de arquivo do entrypoint do servidor ao fazer build para SSR.
Esse entrypoint geralmente depende em qual provedor você está fazendo o deploy e será
definido pelo seu adaptador por você.

Note que é recomendado que este arquivo termine com `.mjs` para que o runtime
detecta que o arquivo é um módulo JavaScript.

```js
{
  build: {
    serverEntry: 'main.mjs'
  }
}
```

### build.redirects

<p>

**Tipo:** `boolean`<br />
**Padrão:** `true`<br />
<Since v="2.6.0" />
</p>

Especifica se os redirecionamentos são enviados como HTML durante a build.
Essa opção só se aplica para o modo `output: 'static'`; em SSR os redirecionamentos
são tratados da mesma forma que todas as respostas.

Essa opção é principalmente para ser usada por adaptadores que possuem arquivos
de configuração especiais para redirecionamentos e não precisam/querem redirecionamentos baseados em HTML.

```js
{
  build: {
    redirects: false
  }
}
```

### build.inlineStylesheets

<p>

**Tipo:** `'always' | 'auto' | 'never'`<br />
**Padrão:** `auto`<br />
<Since v="2.6.0" />
</p>

Controla se os estilos do projeto são enviados para o navegador em um arquivo CSS separado ou em linha em tags `<style>`. Escolha entre as seguintes opções:
  - `'always'` - estilos do projeto são embutidos em tags `<style>`
  - `'auto'`   - apenas folhas de estilo menores que `ViteConfig.build.assetsInlineLimit` (padrão: 4kb) são embutidas. Caso contrário, estilos do projeto são enviados em folhas de estilo externas.
  - `'never'`  - estilos do projeto são enviados em folhas de estilo externas

```js
{
  build: {
    inlineStylesheets: `never`,
  },
}
```

## Opções de pré-carregamento

<p>

**Tipo:** `boolean | object`
</p>

Habilita o pré-carregamento de links no seu site para oferecer transições de páginas mais rápidas.
(Habilitado por padrão em páginas que usam o roteador `<ViewTransitions />`. Defina `prefetch: false` para optar por não ter esse comportamento.)

Essa configuração adiciona um script de pré-carregamento automaticamente em todas as páginas no projeto
lhe dando acesso ao atributo `data-astro-prefetch`.
Adicione esse atributo em qualquer link `<a />` em sua página para habilitar o pré-carregamento para aquela página.

```html
<a href="/sobre" data-astro-prefetch>Sobre</a>
```
Customize mais o comportamento padrão de pré-carregamento utilizando as opções [`prefetch.defaultStrategy`](#prefetchdefaultstrategy) e [`prefetch.prefetchAll`](#prefetchprefetchall).

Veja o [guia de Pré-carregamento](/pt-br/guides/prefetch/) para mais informações.

### prefetch.prefetchAll

<p>

**Tipo:** `boolean`
</p>

Habilita o pré-carregamento para todos os links, incluindo aqueles sem o atributo `data-astro-prefetch`.
Esse valor padrão é `true` quando é utilizado o roteador `<ViewTransitions />`. Caso contrário, o valor padrão é `false`.

```js
prefetch: {
  prefetchAll: true
}
```

Quando definido como `true`, você pode desabilitar o pré-carregamento individualmente definindo `data-astro-prefetch="false"` em links individuais.

```html
<a href="/sobre" data-astro-prefetch="false">Sobre</a>
```

### prefetch.defaultStrategy

<p>

**Tipo:** `'tap' | 'hover' | 'viewport' | 'load'`<br />
**Default:** `'hover'`
</p>

A estratégia de pré-carregamento padrão a ser usada quando o atributo `data-astro-prefetch` está definido em um link sem nenhum valor.

- `'tap'`: Pré-carregar imediatamente antes de você clicar em um link.
- `'hover'`: Pré-carregar ao passar o ponteiro por cima ou focar no link. (padrão)
- `'viewport'`: Pré-carregar conforme os links entram na janela de exibição.
- `'load'`: Pré-carregar todos os links quando a página for carregada.

Você pode sobrescrever esse valor padrão e selecionar uma estratégia diferente para cada link individual definindo um valor no atributo.

```html
<a href="/sobre" data-astro-prefetch="viewport">Sobre</a>
```

## Opções do Servidor

Customize o servidor de desenvolvimento do Astro, usado por `astro dev` e `astro preview`.

```js
{
  server: { port: 1234, host: true }
}
```

Para definir uma configuração diferente baseada no comando run ("dev", "preview") uma função também pode ser passada para esta opção de configuração.

```js
{
  // Exemplo: Use a sintaxe de função para customizar com base no comando
  server: ({ command }) => ({ port: command === 'dev' ? 4321 : 4000 })
}
```

### server.host

<p>

**Tipo:** `string | boolean`<br />
**Padrão:** `false`<br />
<Since v="0.24.0" />
</p>

Define em quais endereços de IP da rede o servidor deve ser escutado em (ou seja, IPs que não sejam localhost).
- `false` - não o expõe em um endereço de IP da rede
- `true` - escutado em todos os endereços, incluindo endereços LAN e públicos
- `[endereço-customizado]` - o expõe ao endereço de IP da rede em `[endereço-customizado]` (ex: `192.168.0.1`)

### server.port

<p>

**Tipo:** `number`<br />
**Padrão:** `4321`
</p>

Define em qual porta o servidor deve ser escutado.

Se a porta indicada já estiver em uso, Astro irá automaticamente tentar a próxima porta disponível.

```js
{
  server: { port: 8080 }
}
```

### server.open

<p>

**Tipo:** `string | boolean`<br />
**Padrão:** `false`<br />
<Since v="4.1.0" />
</p>

Controla se o servidor de desenvolvimento deve abrir em seu navegador ao iniciar.

Passe uma URL completa (e.g. "http://example.com") ou um nome de caminho (e.g. "/sobre") para especificar qual URL será aberta.

```js
{
  server: { open: "/sobre" }
}
```

### server.headers

<p>

**Tipo:** `OutgoingHttpHeaders`<br />
**Padrão:** `{}`<br />
<Since v="1.7.0" />
</p>

Define headers de resposta HTTP customizados a serem enviados em `astro dev` e `astro preview`.

## Opções de Imagem


### image.endpoint

<p>

**Tipo:** `string`<br />
**Padrão:** `undefined`<br />
<Since v="3.1.0" />
</p>

Define o endpoint a ser utilizado para otimização de imagem em desenvolvimento e SSR. Defina como `undefined` para utilizar o endpoint padrão.

Esse endpoint sempre será injetado em `/_image`.

```js
{
  image: {
    // Exemplo: Use um endpoint de imagem customizado
    endpoint: './src/image-endpoint.ts',
  },
}
```

### image.service

<p>

**Tipo:** `Object`<br />
**Padrão:** `{entrypoint: 'astro/assets/services/sharp', config?: {}}`<br />
<Since v="2.1.0" />
</p>

Defina que serviço de imagem será usado para o suporte de assets do Astro.

O valor deve ser um objeto com um entrypoint para o serviço de imagem a ser usado e opcionalmente, um objeto de configuração para passar ao serviço.

O entrypoint do serviço pode ser tanto um dos serviços inclusos ou um pacote de terceiros.

```js
{
  image: {
    // Exemplo: Habilite o serviço de imagem baseado no Sharp
    service: {
      entrypoint: 'astro/assets/services/sharp',
      config: {
        limitInputPixels: false,
      }
    }
  },
}
```

#### image.service.config.limitInputPixels

<p>

**Tipo:** `number | boolean`<br />
**Padrão:** `true`<br />
<Since v="4.1.0" />
</p>

Define se o tamanho das imagens que serviço de imagem Sharp vai processar deve ser limitado.

Defina como `false` para ignorar o limite de tamanho de imagem padrão para o serviço de imagem Sharp e processar imagens maiores.

### image.domains

<p>

**Tipo:** `Array.<string>`<br />
**Padrão:** `{domains: []}`<br />
<Since v="2.10.10" />
</p>

Define uma lista de domínios de fonte de imagem permitidos para otimização de imagem local. Nenhuma outra imagem remota vai ser otimizada pelo Astro.

Essa opção requer uma matriz de nomes de domínio individuais como strings. Coringas não são permitidos. Ao invés disso, use [`image.remotePatterns`](#imageremotepatterns) para definir uma lista de padrões de URL de origens permitidos.

```js
// astro.config.mjs
{
  image: {
    // Exemplo: Permitir otimização de imagem remota de um único domínio
    domains: ['astro.build'],
  },
}
```

### image.remotePatterns

<p>

**Tipo:** `Array.<RemotePattern>`<br />
**Padrão:** `{remotePatterns: []}`<br />
<Since v="2.10.10" />
</p>

Define uma lista de padrões de URL de origem de imagem permitidos para otimização de imagem local.

`remotePatterns` pode ser configurado com quatro propriedades:
1. protocol
2. hostname
3. port
4. pathname

```js
{
  image: {
    // Exemplo: permitir processamento de todas as imagens do seu bucket do aws s3
    remotePatterns: [{
      protocol: 'https',
      hostname: '**.amazonaws.com',
    }],
  },
}
```

Você pode usar coringas para definir os valores permitidos de `hostname` e `pathname` como descrito abaixo. Caso contrário, apenas os valores exatos fornecidos serão configurados:
`hostname`:
  - Comece com '**.' para permitir todos os subdomínios ('termina com').
  - Comece com '*.' para permitir apenas um nível de subdomínio.

`pathname`:
  - Termine com '/**' para permitir todas as sub-rotas ('começa com').
  - Termine com '/*' para permitir apenas um nível de sub-rota.

## Opções da Barra de ferramentas de Desenvolvimento


### devToolbar.enabled

<p>

**Tipo:** `boolean`<br />
**Padrão:** `true`
</p>

Habilita a barra de ferramentas de desenvolvimento do Astro. Essa barra de ferramentas lhe permite inspecionar as ilhas de sua página, ver auditorias úteis sobre performance e acessibilidade, e mais.

Essa opção tem como escopo o projeto inteiro, para desabilitar a barra de ferramentas apenas para você mesmo, rode `npm run astro preferences disable devToolbar`. Para desabilitar a barra de ferramentas para todos os seus projetos Astro, rode `npm run astro preferences disable devToolbar --global`.

## Opções de Markdown


### markdown.shikiConfig

<p>

**Tipo:** `Partial<ShikiConfig>`
</p>

Opções da configuração do Shiki. Veja [a documentação da configuração de Markdown](/pt-br/guides/markdown-content/#configuração-do-shiki) para entender como configurá-lo.

### markdown.syntaxHighlight

<p>

**Tipo:** `'shiki' | 'prism' | false`<br />
**Padrão:** `shiki`
</p>

Qual syntax highlighter deve ser utilizado, caso utilize.
- `shiki` - utiliza o highlighter do [Shiki](https://github.com/shikijs/shiki)
- `prism` - utiliza o highlighter do [Prism](https://prismjs.com/)
- `false` - não aplica syntax highlighting.

```js
{
  markdown: {
    // Exemplo: Mudando para utilizar prism como syntax highlighter em Markdown
    syntaxHighlight: 'prism',
  }
}
```

### markdown.remarkPlugins

<p>

**Tipo:** `RemarkPlugins`
</p>

Passe [plugins remark](https://github.com/remarkjs/remark) para customizar como seu Markdown é construído. Você pode importar e aplicar a função do plugin (recomendado), ou passar o nome do plugin como uma string.

```js
import remarkToc from 'remark-toc';
{
  markdown: {
    remarkPlugins: [remarkToc]
  }
}
```

### markdown.rehypePlugins

<p>

**Tipo:** `RehypePlugins`
</p>

Passe [plugins rehype](https://github.com/remarkjs/remark-rehype) para customizar como o HTML resultante do seu Markdown é processado. Você pode importar e aplicar a função do plugin (recomendado), ou passar o nome do plugin como uma string.

```js
import rehypeMinifyHtml from 'rehype-minify';
{
  markdown: {
    rehypePlugins: [rehypeMinifyHtml]
  }
}
```

### markdown.gfm

<p>

**Tipo:** `boolean`<br />
**Padrão:** `true`<br />
<Since v="2.0.0" />
</p>

Astro usa [GitHub-flavored Markdown](https://github.com/remarkjs/remark-gfm) por padrão. Para desabilitá-lo, defina a flag `gfm` como `false`:

```js
{
  markdown: {
    gfm: false,
  }
}
```

### markdown.smartypants

<p>

**Tipo:** `boolean`<br />
**Padrão:** `true`<br />
<Since v="2.0.0" />
</p>

Astro usa o [formatador SmartyPants](https://daringfireball.net/projects/smartypants/) por padrão. Para desabilitá-lo, defina a flag `smartypants` como `false`:

```js
{
  markdown: {
    smartypants: false,
  }
}
```

### markdown.remarkRehype

<p>

**Tipo:** `RemarkRehype`
</p>

Passe opções para o [remark-rehype](https://github.com/remarkjs/remark-rehype#api).

```js
{
  markdown: {
    // Exemplo: Traduza o texto das notas de rodapé para outra língua, aqui estão os valores padrões em Inglês
    remarkRehype: { footnoteLabel: "Footnotes", footnoteBackLabel: "Back to reference 1"},
  },
};
```

## Integrações

Estenda Astro com integrações customizadas. Integrações são sua via de mão única para adicionar suporte a frameworks (como Solid.js), novas funcionalidades (como sitemaps) e novas bibliotecas (como Partytown).

Leia nosso [Guia de Integrações](/pt-br/guides/integrations-guide/) para mais ajuda em como começar a utilizar Integrações Astro.

```js
import react from '@astrojs/react';
import tailwind from '@astrojs/tailwind';
{
  // Exemplo: Adicione suporte a React + Tailwind no Astro
  integrations: [react(), tailwind()]
}
```

## Vite

Passe opções de configuração adicionais ao Vite. Útil quando o Astro não suporta algumas configurações avançadas que você pode precisar.

Veja a documentação completa do objeto de configuração `vite` em [vitejs.dev](https://vitejs.dev/config/).

#### Exemplos

```js
{
  vite: {
    ssr: {
      // Exemplo: Force um pacote quebrado a pular o processamento SSR, se necessário
      external: ['pacote-npm-quebrado'],
    }
  }
}
```

```js
{
  vite: {
    // Exemplo: Adicione plugins vite customizados diretamente em seu projeto Astro
    plugins: [meuPlugin()],
  }
}
```

## i18n

<p>

**Tipo:** `object`<br />
<Since v="3.5.0" />
</p>

Configura o roteamento i18n e lhe permite especificar algumas opções de customização.

Veja nosso guia para mais informações sobre [internacionalização no Astro](/pt-br/guides/internationalization/)

### i18n.defaultLocale

<p>

**Tipo:** `string`<br />
<Since v="3.5.0" />
</p>

A língua padrão do seu site/aplicação. Esse é um campo obrigatório.

Nenhum formato ou sintaxe específico de língua é imposto, mas sugerimos utilizar letras minúsculas e hífens conforme necessário (e.g. "es", "pt-br") para máxima compatibilidade.

### i18n.locales

<p>

**Tipo:** `Locales`<br />
<Since v="3.5.0" />
</p>

Uma lista com todas as línguas suportadas pelo website, incluindo a `defaultLocale`. Esse é um campo obrigatório.

Idiomas podem ser listados tanto como códigos individuais (e.g. `['en', 'es', 'pt-br']`) ou mapeados para um `path` de códigos compartilhados (e.g.  `{ path: "inglês", codes: ["en", "en-US"]}`). Esses códigos serão utilizados para determinar a estrutura de URLs do seu site deployado.

Nenhum formato ou sintaxe específico de língua é imposto, mas as pastas content os arquivos do seu projeto dever coincidir exatamente com os itens na lista de `locales`. No caso de múltiplos `codes` apontando para um prefixo de URL customizado, armazene seus arquivos de conteúdo em uma pasta com o mesmo nome que o `path` configurado.

### i18n.fallback

<p>

**Tipo:** `Record.<string, string>`<br />
<Since v="3.5.0" />
</p>

A estratégia de fallback para quando navegar para uma página que não existe (e.g. uma página traduzida ainda não foi criada).

Use esse objeto para declarar a rota `locale` de fallback para cada idioma que suprotar. Se nenhum fallback for especificado, então páginas indisponíveis retornarão 404.

##### Exemplo

O exemplo a seguir configura a estratégia fallback do seu conteúdo para redirecionar páginas indisponíveis em `/pt-br/` para suas versões `es`, e páginas indisponíveis em `/fr/` para suas versões `en`. Páginas `/es/` indisponíveis retornarão 404.

```js
export default defineConfig({
  i18n: {
    defaultLocale: "en",
    locales: ["en", "fr", "pt-br", "es"],
    fallback: {
      pt: "es",
      fr: "en"
    }
  }
})
```

### i18n.routing

<p>

**Tipo:** `Routing`<br />
<Since v="3.7.0" />
</p>

Controla a estratégia de roteamento para determinar as URLs do seu site. Defina isso baseado nas configurações de caminho de pasta/URL para seu idioma padrão.

#### i18n.routing.prefixDefaultLocale

<p>

**Tipo:** `boolean`<br />
**Default:** `false`<br />
<Since v="3.7.0" />
</p>

Quando `false`, somente idiomas não-padrão exibirão um prefixo de idioma.
A `defaultLocale` não exibirá um prefixo de idioma e arquivos de conteúdo não existem em uma pasta localizada.
URLs terão o formato `example.com/[língua]/conteudo/` para todos os idiomas não-padrão, mas `example.com/conteudo/` para a língua padrão.

Quando `true`, todas as URLs exibirão um prefixo de idioma.
URLs terão o formato `example.com/[língua]/conteudo/` para todas as rotas, incluindo o idioma padrão.
Pastas localizadas são utilizadas para todos os idiomas, incluindo o padrão.

## Flags Legado

Para ajudar usuários a migrarem entre versões do Astro, nós ocasionalmente introduzimos flags `legacy`.
Estas flags te permitem optar por um descontinuado ou antigo comportamento do Astro
na versão mais recente, para que então você possa continuar atualizando e se aproveitando de novas versões do Astro.

## Flags Experimentais

Astro oferece flags experimentais para dar aos usuários acesso antecipado a novas funcionalidades.
Não há garantia que essas flags são estáveis.

### experimental.optimizeHoistedScript

<p>

**Tipo:** `boolean`<br />
**Padrão:** `false`<br />
<Since v="2.10.4" />
</p>

Previne que scripts de componentes não utilizados sejam incluídos em uma página de forma inesperada.
A otimização é feita com base na melhor estimativa e pode inversamente deixar de incluir scripts utilizados. Tenha certeza de que checou as páginas da sua build antes de publicar.
Habilite a otimização por análise de scripts hoisted adicionando a flag experimental:

```js
{
  experimental: {
    optimizeHoistedScript: true,
  },
}
```

### experimental.contentCollectionCache

<p>

**Tipo:** `boolean`<br />
**Padrão:** `false`<br />
<Since v="3.5.0" />
</p>

Habilita um cache persistente para coleções de conteúdo ao fazer o build em modo estático.

```js
{
  experimental: {
    contentCollectionCache: true,
  },
}
```

